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Abstract. Previous work has shown a tight relationship between databases 
and categories. In the present paper we extend that connection to show that 
certain queries and constraints correspond to the algebro-topological notion of 
lifting problems. In our formulation, each so-called SPARQL graph pattern 
query corresponds to a lifting problem, and each solution to the query cor- 
responds to a lift. We interpret constraints within the same formalism and 
then investigate some formal properties of queries and constraints, e.g. their 
behavior under data migration functors. 
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1. Introduction 

In [JoM] , a tight connection between database schemas and the category-theoretic 
notion of "sketches" was presented. This connection was carried further in |Spl| 
where schema mapping and data migration were shown to be simple consequences 
of using categories rather than sketches to model schemas. In this paper we shall 
show that classical notions from algebraic topology, in particular the so-called "lift- 
ing problem" approach (see [Qui ), is an excellent model for graph pattern queries 
and constraints (see |PSj ). 

A database consists of a schema (a layout of tables in which columns connect 
one table to another) and an instance (the rows of actual data conforming to that 
schema). One can picture the analogy between databases and topological spaces 
as follows. Imagine that a database instance / is some blob in space, and that 
the schema S is a flat sub-plane onto which / projects. Thus we have some kind 
of continuous map tt: I — > S from a "total space" I to a "base space" S. Points 
in S represent tables, and paths in S represent "foreign key" columns (or iterates 
thereof), which point from one table to another. Over every point s e Sin the base 
space, we can look at the corresponding cross-section tt~ 1 (s) C I of the data blob; 
this will correspond to the set of rows in table s. 

A query on a database instance includes a set of knowns, a set of unknowns, 
and a schema relating them. Thus it consists of two parts: a shape R (the relat- 
ing schema, which includes space for both the knowns and the unknowns) and a 
constraint W (the knowns). The shapes R and W again take the form of a base 
space and a data blob projecting onto it, together with a linking homomorphism 
(a so-called commutative diagram) to the database itself. In other words, a query 
on the database instance tt: I — > S looks like this: 

p 



A result to the query is any mapping £:_/?—>/ making both triangles commute 
(I o m — p, tt o £ = n) in the diagram 




The map t is called a lift, hence the term lifting problem. The idea is that a lift fills 
the result schema R with data from / that is both compatible with the constraint 
W and with the schema S. 

We will now give a simple example from algebraic topology to strengthen the 
image, and then a simple example of databases to ground it. 

Consider an empty sphere (tennis ball), defined by the equations x 2 +y 2 + z 2 = 1; 
call it /. We project it down onto the (x, y)-coordinate plane; call that plane 
S = R 2 . The sphere I serves as the database instance and the plane S serves as 
the schema. A query consists of some result schema mapping to the plane S, say 
a solid disk R (given by z — 0,.t 2 + y 2 < 1), together with some constraints, say 
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on the boundary circle W (given by z — 0, x 2 + y 2 = 1) of the disk. None of 
the algebraic equations above are important, except to define the shapes and maps 
more rigorously. Graphically we have Figure [T] below. 

Figure 1. A topological lifting problem 




This is the setup of the query. The results of the query are all mappings R — > I 
making the two triangles commute, as above. While a query language has not been 
created to perfectly accommodate the topological viewpoint, the query pictured in 
Figure [l] could be written as something like 

SELECT filled_disk 
FROM empty_sphere 

WHERE filled_disk.boundary=empty_sphere. equator 
AND filled_disk .inclusion=cmpty_sphere . proj ection 

This query has exactly two results: the top hemisphere and the bottom hemisphere. 
In each case, the filled disk has been imbedded into the empty sphere in such a way 
that the boundary is the equator and the projection is the unit disk. 

We now duplicate this picture in the database setting. Our example is a bit 
contrived (because we wanted it to fit closely with the topological picture above), 
but it gives the idea. Every person has a mother, a father, a height, and a weight. 
Consider the unusual case in which two children of the same parents have the same 
height and weight. We throw some additional information into the schema for 
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which we have no data (e.g. a table for father's height and weight), just to make 
our example a bit more parallel with the topological case above: R is a filled disk, 
W is its boundary circle, / is a sphere, and S is a plane. Graphically we have 
Figure [2] 



Figure 2. A database query (as lifting problem) 




Again, the results of this query setup are all mappings R — > I making the two 
triangles commute, a condition which ensures that the graphical layout presented 
here is enforced algebraically. Unfortunately, SQL queries do not differentiate a 
schema from an instance of it. But if a bit of leeway is granted, we mean to make 
the following query (where the schema S is assumed): 

SELECT R 
FROM / 
WHERE W 

SPARQL graph pattern queries (see [PSJ are more closely emulated by the lifting 
problem approach than SQL queries are. A SPARQL query is stated in terms of 
(subject, predicate, object) triples, where each position can be filled by a constant 
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or a variable. Here is the relevant query for our picture ([2]): 

(?cliild weight 301bs) 
, , (?child height 25in) 

(?child mother Sue) 
(?child father Bob). 

There are exactly two such solutions, given by children Taylor and Tyler. Again, 
query is a bit degenerate in that all our variables are the same (?child), and 
they are all in the "subject" position; we give a more complete formulation of graph 
pattern queries and a more complete example in Section [4] 

The purpose of this paper is to provide a new and fruitful connection between 
database queries and topological lifting problems. This serves both to strengthen 
the connection between databases and categories and to attach a geometric image 
to database queries. 



1.1. Plan of the paper. We begin in Section [2] with a review of the categorical ap- 
proach to databases (see |Spl| for more details) . Roughly this correspondence goes 
by the following five slogans: schemas as categories, instances as set-valued func- 
tors, updates and typing as natural transformations, schema mapping as functors 
between categories, and data migration as the associated adjunctions. In Section 
|2.3| we also discuss the Grothendieck construction, which will be useful in our pic- 
ture: a database instance can be converted into a so-called data fibration, which we 
will later use extensively to make the parallel with algebraic topology and lifting 
problems in particular. 

In Section [3] we show how various existence and uniqueness constraints (such 
as the constraint that a given foreign key column is surjective) can be framed in 
the language of lifting problems; we give a series of examples and develop some 
constraint implications. In Section[3]we discuss queries as lifting problems, and the 
paper's main example is split up into three parts: Examples |4.0.4| |4.2.2| and |4. 2.3] 
In Section [5j the most technical section of the paper, we investigate some formal 
properties of the mathematical objects involved: how to obtain new data fibrations 
from old, how solutions are functor ially related to queries, and how queries behave 
under data migration. Finally in Section [6] we briefly discuss some possible direc- 
tions for future work, including tying in to Homotopy Type Theory (in the sense 
of |Awo] and [Voc ) and other projects. 

1.2. Notation. We use the notation {*} to denote a set with one element. Given 
any category C, we denote the category of all functors C — > Set by C-Set. The 
terminal object in C-Set sends each object in C to {*}; we denote it by !c : C — >• Set. 
We use [0] to denote a discrete category with one object. For any category C, there 
is a one-to-one correspondence between the objects in C and the functors [0] — > C. 
Thus we may denote an object c G Ob(C) by a functor [0] A C. 

We draw schemas in one of two ways. When trying to save space, we draw our 
objects as concisely-labeled bullets and our morphisms as concisely-labeled arrows; 
when trying to be more expressive, we draw our objects as text boxes and put as 
much text in them (and on each arrow) as is necessary to be clear (see |SKJ). For 
example, we might draw the indexing category for graphs in either of the following 
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ways: 




an edge 



has as source 



has as target 



a vertex 



Given two categories there are many functors from one to the other, but if the 
objects and arrows are labeled, there are many fewer that roughly respect those 
labclings. We will generally be explicit when defining functors, but we will also 
take care to have our functors respect labeling to the extent possible. 



1.3. Acknowledgments. I would like to thank Eric Prud'hommeaux for telling 
me about graph pattern queries in SPARQL, and Henrik Forssell for many useful 
discussions. 



2. Database schemas and instances 

2.1. Review of the categorical description of databases. The basic mantra 
is that a database schema is a small category S and an instance is a functor S : S — > 
Set, where Set is the category of setsjj To make all this clear, we take liberally 
from |Spl|, though more details and clarification are given there. Readers who are 
familiar with the basic setup can skip to Section [2. 3. 1| 

Definition 2.1.1. A database schema or simply a schema, is a small category S. 
An object s of S is called a table in S, and an arrow / : s — > s' is called a column of 
s valued in s'. The identity map id s : s — > s is called the primary id column of s. 

A database instance or simply an instance on schema S is a functor 7: S — > Set. 
Given an object s £ Ob(S'), an element x £ 7(s) is called a row-id ofj(s). We refer 
to a pair (x, /), where a; is a row-id of j(s) and /: s — > s' is a column of s, as a 
cell in 7(s), and to each cell (x, /) the element r y(f)(x) £ j(s') is called the value 
of the (x, f)-cell. 



Remark 2.1.2. Another way to look at Definition 2.1.1| is as a kind of "normal form 



for a database. Suppose we say that a database is in categorical normal form if 

• every table s has a single primary key column id s , chosen at the outset. 
The cells in this column are called the row-ids of s; 

• for every column / of a table s there is some table s' such that the value 
in each cell of s refers to some row-id of s'; and 

• each "pure data" column of s (with values in some set, say the set of strings) 
is considered a foreign key column to a 1-column table whose cells are values 
of the given set (e.g. all strings). These 1-column tables do not have to be 
physically stored, but that issue is hidden. 

The point is that every column in every table is considered a foreign 

key. Even a column consisting of literal strings is a foreign key to some 1-column 
table. An example should make this more clear. 



4n practice, it is often useful to assume that S is a finite category (i.e. that it has finitely many 
objects and morphisms) and that 8 : S — > Fin, where Fin C Set is the category of finite sets. 
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Example 2.1.3. A database in categorical normal form consists of a bunch of tables. 
Each has a primary id column, and perhaps other columns. For example, consider 
these tables: 



(2) 



Employee 


Id 


First 


Last 


Mgr 


Dpt 


101 


David 


Hilbert 


103 


qlO 


102 


Bertrand 


Russell 


102 


x02 


103 


Alan 


Turing 


103 


qlO 



Department 


Id 


Name 


Seer 


qlO 


Sales 


101 


x02 


Production 


102 



Every column in a table refers to the primary id column of another table - every 
column is a "key column." This will be shown graphically in Diagram Q, but lets 
look at the Employee table. 

• the Id column refers to the Employee table, 

• the First and Last columns refer to the Strings table (see (J3j) below), 

• the Mgr column refers to the Employee table, and 

• the Dpt column refers to the Department table. 

One should quickly check that in all cells in the Dpt column refer to row- ids 
in the Department table. 

As explained in Remark |2.1.2| even a data column such as Name in a table T is 
considered a foreign key to some one-column table. Such a one-column tables (e.g. 
of strings) may be thought of as containing the active domain of the Name column 
(all the names appearing in that column of T) or even as containing all strings. For 
clarity let's use the latter, the table of all strings, here. The table of strings can 
be considered "virtual" — one can never load its entirety into memory nor view it. 
Here is a sample of it: 



(3) 



Strings 



Id 



The way the above three tables interact (in terms of how their columns refer to 
one another) is called the schema for this database. The current paper sets out 
from the observation made in |Spl| that schemas can be considered as categories. 
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In this case the relevant category is drawn: 



(4) 



S 



Mgr 

_ Employee 


Dpt 


>- 9 Department 


m 




Sccr 




First 

\ J 


Last 


^^■^"^ Name 




^String 







Each object s £ Ob(S), drawn as a dot, corresponds to a table. The arrows out 
of an object s correspond to columns of table s. Note that we never draw identity 
arrows (as they arc implied) nor do we draw "free compositions" of arrows. For 
example the arrow 

First o Seer: . D °P artmont — > .string 

is not drawn in Diagram Q ; this is akin to the fact that the Department table does 
not need a column for the secretary's first name. See |Spl[ Section 1.2] for more on 
this. 

The advantage of categories over graphs is the ability to declare different paths 
(having the same start and end node) to be equivalent. For example, consider the 
"business rule" that every employee must be in the same department as his or her 
manager. Thus the following two paths from , Em pi°y ec to ^cp 3 - 1 '*™™* are declared 
equivalent : 

Dpt 



-Employee 



^Depart 




Dpt 



.Employee 



By this declaration, we guarantee that every record in the Employee table ends 
up at the same record in the Department table, regardless of which route we take. 
We could similarly declare that the secretary of any department must be in that 
department. We write these path equivalences on S as equations: 

Dpt o Mgr = Dpt; 

Dpt O Seer = id D cpartmcnt • 

Thus we see how the above schema can be understood as a category, S. One 
should also see that specifying a set of rows in the Employee table, the Department 
table, and the String table constitutes specifying a functor 7: S — » Set. To each 
object s 6 Ob(5) we have written a set j(s) (the set of row-ids for that table), and 
to each arrow / : s — > s' in 5* we have defined a function of sets (given by the / 
column) . 

Database overview: a database schema consists of tables and "column- 
headers"; an instance on a schema coherently assigns to each table a set of 
rows and to each column their respective values. 

Category overview: a category S consists of objects and arrows; a functor 
7 : S — > Set coherently assigns to each object a set of "instances" and to 
each arrow their respective values. 
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Definition 2.1.4. Let S be a database schema and let 5, e: S — > Set be instances 
(set- valued functors) on S. An instance homomorphism is a natural transformation 
H : 8 — !> e of functors. Given a table s £ Ob(S) and a row-id x S S(s), we refer to 
the row H s (x) € e(s) as its image. 

A natural transformation H : 8 — > e begins by providing, for any table s € Ob(S') 
a function H s from the rows of <5(s) to the rows of e(s). But then for any table 
s, any row x £ <5(s) in s and any column f:s—> s' of s, one can obtain a row-id 
in e(s') in two different ways. The first is look at the 5-value of the (x, /)-cell and 
apply H s i to it. The other is to first apply H s to x to get a row x' = H s (x) £ e(s') 
and then look at the e-value of the (x' , /)-cell. The category-theoretic definition of 
natural transformation is simply the integrity constraint that these answers agree 
for any s, f,x. Formally 



Definition 2.1.5. Given a schema S, we define the instance category of S, denoted 
S-Set, to be the category whose objects are instances 8: S —> Set and whose 
morphisms are instance homomorphisms H : 8 — > e. 

The instance category S'-Set is a topos for any schema S (see [MM ]). This 
implies that the category of instances is cartesian closed, has finite unions and 
quotients, and in particular, supports the typed lambda-calculus. 

2.2. Review of data migration functors and typing. Once the above defini- 
tions are in place, classical category theory gives ready-made tools for migrating 
data between different schemas. The first definition we need is that of schema 
mapping. 

Definition 2.2.1. Let S and T be schemas. A schema mapping is a functor 
F: S ^ T. 

Thus a schema mapping assigns to each table in S a table in T, to each column 
in S a column in the corresponding table of T, and all this in such a way that the 
"business rules" (path equivalences) are preserved. 

Definition 2.2.2. Let F : S — !> T be a schema mapping. Three functors on instance 
categories are induced by F, which we call the migration functors associated to F 
and which we denote by T,p,Af, and LT^?, displayed here: 



The functor A p : T-Set — > S-Set sends an instance 8: T — > Set to the instance 
8 o F: S — > Set. The functor T,p is the left adjoint to Ap, and the functor LT^ 
is the right adjoint to Af . We call Ap the pullback along F , we call T,p the left 
pushforward along F, and we call LT^ the right pushforward along F. 

Details and examples of these migration functors (e.g. their use in joins, unions, 
projects, and other queries) can be found in |Spl . We now briefly and informally 
recall typing for database schemas (again, more details can be found in |Spl| ). One 
major difference between our definition of typing and the usual relational database 
concept is that not all columns need to be typed, only "literal" columns (like Strings 



H s ,(S(f)(x)) = e(f)(H s (x)). 




S-Set 



-A F - 
"57 



T-Set. 
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and Ints). For example cells in primary and foreign key columns may be kept simply 
as "row-ids" or memory locations, without need for a chosen display method. 

We now define typing for a database. Details can be found in |Spl| ; we give an 
informal definition here just for the flavor. 

Definition 2.2.3 (Informal). Let S be a database schema. A type signature on S 
consists of a partial instance r : S — > Set (i.e. a set- valued functor defined only on 
some subcategory of S) in which r(s) is a datatype such as String, Int, or Float, 
for every table s in the domain. A r-typed instance is an instance 8: S — > Set, 
together with an instance homomorphism 5 — > r defined over the domain of r. 

Remark 2.2 A. In past work ( |Spl| ) the author used F* ,F*, and F\ to denote what is 
here denoted as Ap^Hp , and Ef respectively. The current notation is superior for 
three reasons: it causes less confusion with a similar but differently named notion 
from sheaf theory (e.g. see |Har|, p. 65]), it is more consistent with analogous notions 
from dependent type theory and the theory of polynomial functors f |GK| ). and it 
is more suggestive: A is associated to duplication (or projection), LT is associated 
to products, and £ is associated to sums. 

2.3. Data fibrations. There is a well-known construction that associates to a 
functor S: S — > Set, a pair (J(S),ng) where J(S) 6 Cat is a new category, called 
the category of elements of S, and its'. J S — » S is a functor. It is often called the 
Grothendieck construction. The objects and morphisms of J (6) are given as follows 

Ob(/(<J)) :={(s,x) \seOb(S),xeS(s)} 
Romj {S) ((s,x), {s',x')) := {/: a -> s' | 6(f)(x) = x'] 

The functor ng: J(S) — > S is straightforward: it sends the object (s,x) to s and 
sends the morphism /: (s, x) — > (s',x') to /: s — > s' . 

We call the pair (J(S), its) the data fibration associated to S. We will see below 
(Definition 2.3.3) that tts is indeed a kind of fibration in the sense of category 
theory. This construction, and in particular J(S), is also nicely connected with the 



resource descriptive framework (RDF): the arrows 



of / (5) correspond to 



RDF triples (subject, predicate, object). An example should clarify this discussion. 

Example 2.3.1. Recall the database instance 5: S — » Set given by the tables in 
Diagrams ^ and (|3|, whose schema S was presented as Diagram Q. Applying 
the Grothendieck construction to 6: S — > Set, we get a category J(S): 



(5) 



S(s) = 



First Last 



qlO a x02 




Name 
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(where 14 arrows have been left out for ease of reading) . Each arrow can be inter- 
preted as an RDF triple, such as (101 First David) and (x02 Seer 102). 

The functor Tig : f(S) — > S sends objects 101,102,103 in J(S), above, to the 
object Employee, in S, below; it similarly sends the arrow labeled Dpt in J (5) to 
the arrow labeled Dpt in S, etc. Here is Diagram Q again for convenience: 



S 



Mgr 

rs 

.Employee 


Dpt 


>- ^Department 


w 




-< 


Sccr 




First 


\ J 


Last 


^ — Name 




^String 







In the Introduction (Section [lj, we discussed database instances in terms of 
mappings tt from "data blobs" I to "schema shapes" S. We were referring to 
exactly the above data fibration picture. In those terms Example 1 2 . 3 . 1 1 would have 
I = J(S) and 7T = tt s : I -> S. 

We have been calling the map ng: J (5) — > S a "data fibration", but there 
is a more common term which, to the author, seemed overly technical for the 
context of this paper. Namely, a functor ng: f(S) — >• C obtained by applying the 
Grothendieck construction to a set- valued functor 5: C — > Set is usually called a 
discrete opfibration. In a moment we will give a definition of data fibrations in 



terms of lifting problems (Definition 2.3.3), which serves as a nice introduction to 
the subject of this paper. 

We understand a data fibration tt : I — > S as follows. Given an object s € Ob(S'), 
we consider the fiber 7r _1 (s), and given a morphism /: s — > s' in S we consider 
how fibers tt~ 1 (s) and 7r _1 (s') relate. If tt were not assumed to be a data fibration 
but instead just a general functor, then all we would know about these various 
fibers would be that they are categories. But the first distinctive feature of a data 
fibration is that tt~ 1 (s) is a discrete category, i.e. a set, for each object s € S; that 
is, there are no morphisms between different objects in a chosen fiber. The pre- 
image 7r _1 (/) of / : s — s- s' is a set of morphisms from objects in tt~ 1 (s) to objects in 
7r _1 (s'). In fact, there is exists a unique morphism in 7T~ 1 (f) emanating from each 
object in 7r~ 1 (s), so ir~ 1 (f) can be cast as a function 7r _1 (/): tt~ 1 (s) — > tt~ 1 (s'). 

To recap, the data fibration irg : J(S) — > S of a set-valued functor 5: S -4 Set 
has the same information as S; it is merely a different perspecitve. We have 



nj\s) = 5(8) 
for any s, s' S Ob(S') and / 



and 



_1 (/)=<*(/), 



s -4 S 



2.3.1. Groupoids in algebraic topology. In algebraic topology (sec May ), one as- 
sociates to every topological space X a fundamental groupoid Gpd(X). It is a 
category whose objects are the points of X and whose set of morphisms between 
two objects is the set of continuous paths from one point to the other. Two paths 
are considered equivalent if one can be deformed to the other (without any part of 
it leaving X). Composition of morphisms is given by concatenation of paths. 

One can reduce some of the study of the space X to a study of this algebraic 
object Gpd(X), and the latter is well-suited for translation to the language of 
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this paper. For example, the category Gpd(X)-Set is roughly equivalent to the 
category Cov(X) of covering spaces tt: E — > X, except without the requirement 
that tt be surjective. More precisely, Cov(X) is equivalent to the full subcategory 
of Gpd(X)-Set spanned by those functors 5: Gpd(X) — s- Set such that S(g) + 
for all g G Gpd(X). See |May[ Definition on p. 22-23, and Corollary on p. 32] for 
details. 

Example 2.3.2. Suppose that G is a groupoid (a category in which every morphism 
is an isomorphism). Then a covering of groupoids in the sense of |May| Section 4.3] 
is precisely the same as a surjective data fibration with schema G. 

Let G = Gpd^S 1 ) denote the fundamental groupoid of the circle with circum- 
ference 1. We have Ob(G) = {0 G R}/ ~, where 9 ~ 6' if 6 - 9' € Z; and we 
have 

Hom G (0, 9') = {x G R | x + 9 ~ 9'}. 

Think of G as the category whose objects are positions of a clock hand and whose 
morphisms are arbitrary durations of time (rotating the hands from one clock po- 
sition around and around to another) . Consider the functor T: G — >• Set such that 
T(6>) = {t € R | t-9 G Z} and such that for x G Hom G (6>, 9') we put T{x){t) = x+t. 
So, for a clock position 9, the functor T returns all points in time at which the clock 
is in position 9, with the obvious action of time durations. 

Applying the Grothendieck construction to T, we get a covering tt : J (T) — > G, 
which corresponds to the universal cover of the circle S 1 . One can think of it as a 
helix (modeling the time line) mapping down to the circle (modeling the clock) . 

A much more sophisticated example may be found in [Mor]. 

2.3.2. Data fibrations via lifting constraints. Our goal now is to express the notion 
of data fibrations in terms of lifting constraints. In other words, we will exhibit 
a finite set of functors {m a : W a — !> R a }aeA that serve to "check" whether an 
arbitrary functor tt: I — s- S is a data fibration. In fact, Definition |2 . 3 . 3| will define tt 
to be a data fibration if and only if it satisfies two universal lifting constraints 
171%: W\ — !> R\ and m-i : W% — > R2; that is, for each solid-arrow commutative 
diagram of the form 

W a >I a €{1,2} 



¥ / Y 
R a >- S 

there exists a dotted arrow "lift" functor, as shown, making the two triangles com- 
mute. We call these two functors the universal constraint functors for data fibra- 
tions. They are displayed in Figure [3] 



In Figure [3] the category Ri = R 2 = [1] is drawn. For any category S, a functor 
[1] — > S is the same thing as a morphism /: s s' in S. A functor tt: I — > S 
satisfies the lifting condition with respect to mi iff there exists a morphism in 
7r_1 (/) emanating from each object in 7r -1 (s); and tt satisfies the lifting condition 
with respect to m-i iff there is at most one morphism in 7r _1 (/) emanating from 
each object in tt^ 1 (s). Thus we have expressed data fibrations in terms of lifting 
conditions, and we formalize this in Definition |2. 3. 3| 
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Figure 3. The universal constraint functors for data fibrations 
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mjaj-a 



l/V, 




R 2 = 



Definition 2.3.3. Let / and S be categories and let tt: I — > S 1 be a functor. Then 
/ is a data fibration if, for each solid-arrow commutative diagram of the form 

W a ^1 ae{l,2}, 



R a >- ,S 

where mj and m 2 are the functors from Figure [3j there exists a dotted arrow 
functor, as shown, making the two triangles commute. 

In the remainder of this section we give some consequences of Definition |2.3.3| 
The proofs may be challenging for beginners and may be skipped on a first reading. 

Proposition 2.3.4. Let n: I — >• S be a data fibration. Then for each object s S 
Ob(S') the fiber ir^ 1 (s) is a discrete category. 

Proof. Let s E Ob(5 l ) be an object, and let g: x — > y be a morphism in the fiber 
tt (s) C /; we will show that x = y and that g = id x is the identity morphism. 
Consider the map m 2 : W 2 — > R 2 from Figure [3] Let n : R 2 — > S be the functor 
sending / to id s . Let p: W 2 — > I send f\ to id^ and send f 2 to g. We have a lifting 
diagram as in Definition |2. 3. 3[ so a lift is guaranteed. This lift equates id x and g. 

□ 



The following proposition is useful in the theory of computation. 
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Proposition 2.3.5. Let A^ 0,1 ' 2 ^ and A^ 0,1 ' 2 ^ denote the categories pictured as the 
source and target of the arrow m below 





^{0,1,2} j S j us £ a commu tative triangle) and let m be the unique functor that pre- 
serves our labeling of objects, 0,1,2. If n: I — > S is a data fibration then it satisfies 
the lifting condition with respect to m. 



Proof. We will use notation from |DSI Section 1.8]. Suppose that 7r: / — > S is a 
data fibration. We extend our lifting problem to the solid arrow diagram 

,{0,1,2} 



AW 



A* 1 ' 2 } 



A 



A* ' 1 ' 2 ! 



Y 

•5 



where the right-hand square is the diagram for which we want a lift. By Definition 
|2.3.3| (applicable since the left-hand map m\ is one of the functors in Figure [3j, 
there exists a dotted arrow lift making the diagrams commute. If we let X — 
colim(A^ 2 > <- A« -4 Aj 0,1 ' 2} ), which one might call the "non-commutative 
triangle", then it suffices to find a lift for the induced diagram 

X 5- / 



S. 



We again extend to get the solid arrow diagram 

{0,2,2'} 9 



A 



A{°. 2 1 



X 



.^{0,1.2} 



s 



where g sends the two generating arrows to the two non-equal paths 



X. Again by Definition 2.3.3 (applicable since the left-hand map m 2 is one of the 
functors in Figure [3]) , we have a dotted arrow lift making the diagrams commute. 



Setting Y = colim(A{°' 2 > 
diagram 



m 2 »{0,2,2'} 



X), it suffices to find a lift for the 



Y 



S. 



But now one can check that the left-hand map Y — > A^° :1,2 ^ is an isomorphism, so 
we are done. 

□ 
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Proposition 2.3.6. Let n : I — > S be a data fibration. Then 7r is faithful. In other 
words, for any two objects i,j € Ob(J) the function 

it: Hom/(i, j) -> Hom s (7r(i), ir(j)) 

is injective. 

Proof. There are multiple ways to prove this, but we will use the lifting definition 



(Definition 2.3.31 for practice. Suppose given a lifting problem of the form 

^1 



•* 




m 


t 




— > » j 



where m is the label-preserving inclusion and n is arbitrary. Each dotted lift £ is 
an element of Hom/(i, j) mapping to n € Homs(7r(i),7r(j)), so we must show that 
there is at most one such lift. But by Definition |2.3.3| there exists exactly one lift 
£' for the outer rectangle in the diagram 



•* 











•* 


•3 




- " t 




. m ' 




r / 




— > «j 



s 



and it follows that there is at most one lift serving as 



The following Lemma is important for understanding the basic behavior of the 
Grothendieck construction. 

Lemma 2.3.7. Let S be a category. Given two instances, 8,e: S — > Set, there is 
a natural bijection 

P: Hom s _set(<5,e) A Hom C at /s (J (S)J(e)). 

Proof. Given a natural transformation a : S — > e we first provide a commutative 
triangle 



(0) 



s 

For any object s £ Ob(S'), we are given a s : S(s) e(s). We define P a on an object 
(s,x) € J(S), where x € 5(s), by P a (s,x) = (s,a s (x)). For a morphism f:s—>s' 
such that S(s)(x) = x' , define P a (f) '■= e(/) : a s {%) —> a s /(x'). 

It is similarly easy to show that given a commutative triangle as in we get 
a natural transformation S — > e, and that these two correspondences are mutually 
inverse. 

□ 
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In Propositions [2A8] and |2~3~9l we discuss some aspects of the relationships 
between the Grothendieck construction and the migration functors A and S (see 
Definition 2.2.21. We will discuss each of these, as well as the functor II, more in 



Section 15.31 

Proposition 2.3.8. Let F : S -4 T be a functor. Let S: S -4 Set and e: T 

be instances, and suppose we have a commutative diagram 



Set 



(7) 



->■ T. 



Then diagram is a pullback, i.e. J(S) = S x-r /(e), if and only if 5 = Ape. 

Proof. This is checked easily by comparing the set of objects and the set of mor- 
phisms in J(5) with the respective sets in S Xt /(e). 



Let S be a category. We define a functor d: Cat/ S — > S-Set as follows. For any 
F: X — > S, let lx ■ X — > Set denote the terminal object of X-Set (see Notation 
Tty , and note that J(\ x ) = X in Cat /x . Define d(F) : S -4- Set as 

8(F) := S F (! X ). 
We have the following proposition. 

Proposition 2.3.9. (1) The functor d is left adjoint to J : 

a 



Cat 



: S'-Set. 



(8) 



(2) The functor J : 5-Set — > Cat/ S is fully faithful, so for any 7: S — > Set 
we have an isomorphism 

d 0/(7) = 7. 

(3) An object X — > S in Cat /g is a data fibration if and only if X = / d(X). 

Proof. Let F: X -4 S be an object of Cat/ 5 and let 7: S — > Set be an object of 
S'-Set. By Proposition 2.3.8| we have a pullback diagram: 



X 



so we prove statement (1) as follows: 

Hom C at /s (X,/( 7 )) s Homcat /x (X,/(A F7 )) 

s Hom X -set(!x, A F 7) s Homs_ Set (E F ! J( :, 7) 



where the second isomorphism follows from Lemma |2.3.7 Statement (2) follows 
from the same lemma together with [MM, Section 7.4]. 
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By construction, 7r: j(S) — > S is a data fibration for any 5: S — > Set, so if 

X -^-> S is not a data fibration then X ^ J d(F). Thus, it remains to show that 
if F is a data fibration then X = J d(F), but this follows from a straightforward 
comparison of the objects and arrows in each category. 



Remark 2.3.10. Given a schema S, we will usually try to differentiate between 
database instances 8: S — > Set and data fibrations ir: I — > S, even though the 
respective categories are isomorphic by Proposition |2.3.9) 

3. Constraints via lifting conditions 
We have already introduced the topic of constraints via lifting by showing that 



data fibrations are functors that satisfy two lifting conditions (see Definition 2.3.3 1. 
These lifting conditions act as constraints on the database instance, which roughly 
say that any cell in any table is atomic (contains exactly one value). Moreover, 



each of these constraints is universal (see Definition 3.1.41, which roughly means 



that we require it to hold for every column in every table. In this section we will 
generalize and consider non-universal constraints. 

3.1. Basic definitions. 

Definition 3.1.1. Let S € Cat be a database schema. A (lifting) constraint on S 
is a pair (m, n) of functors 

A functor ir: I S is said to satisfy the constraint (m, n) if, for all solid arrow 
commutative diagrams of the form 

(9) W ^ J 




a dotted arrow lift exists making the diagram commute. 

A (lifting) constraint set is a set {W a — ^> R a ^> S | a € ^4}, for some set A. 
A functor ir: I S is said to satisfy the constraint set {(m a , n a)}oeA if it satisfies 
the constraint (m a ,n Q ) for each a £ A. 

Remark 3.1.2. While not all constraints on databases are lifting constraints (for 
example, declaring a table to be the union of two others is not expressible by a 
lifting constraint), we will only be considering lifting constraints in this paper. For 
that reason, we often leave off the word "lifting," as suggested by the parentheses 
in Definition 13.1.11 

Example 3.1.3. Consider the schema 




The category C/-Set is precisely the category of (directed) graphs. Given a graph 
X : Q — > Set, we have a function X(s) : X{E) — > X(V) assigning to every edge its 



18 



DAVID I. SPIVAK 



source vertex. Suppose we want to declare this function to be surjective, meaning 
that every vertex in X is the source of some edge. We can do that with the following 
lifting constraint 




where m and n respect labeling. The graphs that satisfy this constraint are precisely 
those for which every vertex is the source of some edge. 

Definition 3.1.4. Let S E Cat be a schema. Given a functor m: W — > R, define 
a set [m] of lifting constraints as follows: 

[to] = {W^R^S\ne Hom C at(-R, S)}. 
Given a set of functors M — {rrij : Wj — > Rj \ j € J}, the union 

[M] := |J [m,] 
j&J 

is a constraint set, which we call the universal constraint set generated by M. A 
functor 7i : / — > S satisfying the constraint set [M] is called an M-fibration. 

Example 3.1.5. Consider the set M :— {mi, m 2 }, where mi : W\ — > R\ and m 2 : W% - 
i?2 are the functors from Figure [3] Then Definition |2.3.3| defines a data fibration 
to be an Ai-fibration. 

Universal constraints seem to be more important in traditional mathematical 
contexts than in "informational" or database contexts. For example, in the world 
of simplicial sets, the Kan fibrations are Ajf-fibrations for some universal constraint 
set [M], called generating acyclic cofibrations (sec [Hir ). 

3.2. Examples. In this section we will show how to use lifting constraints (see 
Definition 3.1.1 1 to declare a number of different properties for tables in a database. 



Our examples include 

• declaring a table to be non-empty, 

• declaring a table to have exactly one row, 

• declaring a foreign key to be injective, 

• declaring a foreign key to be surjective, 

• declaring a relation to be reflexive, symmetric, and/or transitive, and 

• declaring a table to be a product or a general limit of other tables. 

We will discuss these in order. 

Being able to visualize the first two examples is important if one wishes to 
understand the ideas presented in this paper. After that, visualizing the rest will 
be easier and probably fun. 

Example 3.2.1 (Nonempty). Let S be a schema, and let T E Ob(S) be a table, 
which we want to declare non-empty. We use the constraint drawn as follows 
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where n(A) = T. In other words, we set W\ = to be the empty category, and we 
set R = {A} to be the discrete category with one object, A. To say that the lifting 
problem 

W-i > J 



R 



S 



has a solution is to say that there exists an object in the instance category / whose 
image under ir is T. In other words, there exists a row in table T. Here, the 
commutativity of the upper-left triangle does nothing, and the commutativity of 
the lower-right triangle does all the work. 

Example 3.2.2 (Cardinality=l). Let S be a schema, and T S Ob(5) a table, which 
we want to declare to have exactly one row. We know a constraint guaranteeing 
the existence of a row in T from Example |3. 2. 1[ in Section [33] we will give a general 
method for transforming existence constraints into uniqueness constraints, but here 
we will just give the answer. 

To declare T to have at most one row, we use the constraint drawn as follows: 



-> S 



where m{a\) = m^a^) = A and where n(A) = T. In other words, we set W2 = 
{a 1 ,a 2 } to be a discrete category with two objects, and we set R — {A} to be a 
discrete category with one object. The lifting problem 

W 2 ^1 



R 



S 



has a solution iff both triangles commute. We know already that the image of a 
and b in / consists of two rows in table T, because the square commutes. The 
commutativity of the upper-left triangle commuting implies that any two rows in 
table T are the same, as desired. The commutativity of the lower-right triangle is 
implied by the surjectivity of and the commutativity of the square. 

The set {(mi,n), (m2,n)} is a constraint set on S that is satisfied by a dataset 
/ if and only if / has exactly one row in T. 

We will be more brief from here on out. The following constraint is exactly what 



was used in Example 3.1.3 



Example 3.2.3 (Surjective foreign key). The declaration that a foreign key /: T — > 
T' be surjective is achieved by the constraint: 





F 











-> s 



where m(b) = B and n(F) = f. 
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Example 3.2.4 (Injective foreign key) . The declaration that a foreign key / : T — » T' 
be injective is acheived by the constraint: 




S 



where m(ai) = mia^) — A and m(b) = B, and where n(F) = f. 

There exist constraints that ensure a relation binary relation R C A x A is 
transitive, which we give in Example |3.2.5| There is another constraint to ensure 
it is symmetric, and another to ensure it is reflexive; we leave these as exercises. 

Example 3.2.5 (Transitive relation). The declaration that a relation 

/ 

r — r a 

g 



be transitive is achieved by the constraint 




where the functors m and n should be clear by our labeling. 

A finite limit (in the sense of category theory) can be declared using lifting 
constraints. For conciseness, we only include the example of binary products. The 
case for fiber products is just as easy, but since people with an interest in databases 
see product tables more often than fiber product tables, it seemed preferable to 
explore that case. An interested reader can try the fiber product constraint for 
him- or her-self. 

Example 3.2.6 (Product). Suppose we have a table T and two of its columns are 
/ : T — > U and g : T — > V. The declaration that (the set of rows in) table T is the 
product of (the sets of rows in) tables U and V is achieved by two constraints, an 
existence constraint and a uniqueness constraint. The existence constraint is 
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where mi(b) = B,m\(c) = C, and n(F) = f,n(G) = g. The uniqueness constraint 
is 





where m 2 {F 1 ) = m 2 (F 2 ) = F 1 m 2 (G 1 ) = m 2 (G 2 ) = G, and n(F) = f,n(G) = g. 
Thus the constraint set for (T, /, g) to be a product is {(mi, n), {m 2 , n)}. 

3.3. Encoding uniqueness for const raints. Suppose given a constraint W 
S. According to Definition 



R 

every solid arrow diagram 
(9) 



3.1.1 



W 



a functor tt : I — > S satisfies (m, n) if for 



> / 



R 



■S. 



there exists a dotted arrow lift making it commute. Thus it appears that all con- 
straints are existence declarations. However, we can always turn such an existence 
declaration into a uniqueness declaration using another lifting diagram. In fact 



this was done several times (see Examples 3.2.2 3.2.61 above. Before explaining 
where it comes from, we simply display the uniqueness constraint to spare the busy 
reader. The uniqueness constraint corresponding to (m, n) is 



(10) 



R IIw R 

(id_R,id_R) 

R 



■S. 



Here's why. Suppose that we have two lifts for Diagram 



(11) 



W 



R 



S. 



We encode this in a new (rather abstruse) commutative diagram 
W R ^ / 




which includes no information beyond that in (111, but merely mentions our new 
object R Hjy R- But now, by the universal property of R JIw R, we are set up to 
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see that there exists a solid-arrow commutative diagram 



(12) 



R IIvf R / 



(id R ,id H ) 



R 



S. 



We now suppose that there exists a lift £ as shown in Diagram ( 12 1, and inquire as 
to its meaning. The commutativity of the upper-left triangle implies that I = l\ = 
t%. Because the map (idij,idfl) : RMw R — > R is an epimorphism of categories, the 
commutativity of the lower-right triangle (n£ = n) follows from the commutativity 
of the square — nothing new here. Thus, the constraint given in (10) does indeed 
declare uniqueness of lifts for Diagram ^ . 



3.4. Constraint implications. Propositions 3.4.2 and [3~0| below are constraint 
implication results. That is, they show that instances satisfying one lifting con- 
straint automatically satisfy another. These two constraint implications are not 
exhaustive, they merely give the idea. More are given in Section [5.3| 



Definition 3.4.1. Suppose that one has a diagram of the form 



w — w w 



R 



Rf 



pi 



R 



such that the top and bottom compositions are identity, 

pi o s\ = \dw and P2 ° «2 = idfl. 
In this case we say that m is a retract of m'. 

Proposition 3.4.2. Suppose that (m,n) is a constraint for a schema S and that 
some m is a retract of m! , part of which is shown to the left in the diagram 



W' -^W 

m' "i 

R' >- R > S. 

P2 n 



Then any data fibration 7r: / — > S satisfying (rn',n o p 2 ) also satisfies (m,n). 
Proof. Suppose given a lifting problem 
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We assume by hypothesis that the dotted arrow lift / exists making the solid arrow 
diagram 



w w w 



R 



R' 



P2 



R 



I 



y 
S 



commute. But then / o s 2 : R — > I satisfies the constraint (m, n o p 2 o s 2 ) = (m, n). 



Proposition 3.4.3. Suppose that the square to the left in the diagram 

W ^ W 



R 



R' 



is a pushout. Ifir:I—tS satisfies the constraint (m, nog) then it satisfies (m',n). 

Proof. Given any diagram as to the left, for which we want the dotted lift, we 
compose to get a diagram as to the right, 



w 



R' 



S 




for which the dotted arrow exists by hypothesis. Then since R' is a pushout of the 
lefthand square (in the righthand diagram), the required lift £ exists as well. 



4. Queries as lifting problems 

In this section we will show a correspondence between queries and lifting prob- 
lems, under which solutions to the queries correspond to solutions (i.e. lifts) for 
the lifting problem. We are interested in queries of the kind discussed in Example 

EM 

Example 4.0.4. Suppose you go to a party. You meet and really hit it off with a 
married couple there; the husband's name is Bob and the wife's name is Sue; they 
live in Cambridge. From your conversation, you know that Bob works at MIT and 
Sue works in the financial sector. You'd like to see them again, but you somehow 
forgot to get contact information; in particular you'd like to know their last names. 

This is a typical database query problem. It can be phrased as the following 
SPARQL graph pattern query (which we arrange in two columns for space and 
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readability reasons) : 
(13) 

(?marriage includes_as_husband ?b) (?marriage includes_as_wife ?s) 



(?b has_first_name Bob) 
(?b lives_in Cambridge) 
(?employedb is ?b) 
(?employedb has_employer MIT) 

(?b has_last_name ?bobLast) 



(?s has_first_name Sue) 
(?s lives_in Cambridge) 
(?employeds is ?s) 

(?employeds has_employer ?sueEmp) 
(?sueEmp is_in financial) 
(?s has_last_name ?sueLast) 



The query in ( 13 1 might be asked on the following database schema: 



(14) 



S 



had wed- 



ding on 




a date 





includes as husband 



hides as ' 




an employed 
person 



a person 


first name 


a first name 





has employer 



lives in 



has last 



Y 


c 


L 


an employer 




a city 




a last name 



a sector 



Given that S is instantiated with data 5: S — > Set, one can hope to find Bob and 
Sue, and then determine their last name. Below (specifically in Examples |4 . 2 . 2 1 and 
4.2.3) we will show this query corresponds to a lifting problem for its : J (5) — > S. 



Remark 4.0.5. In Example |4.0.4 our SPARQL query (13 1 only has variables in 
subject and object positions (the nodes of the schema). It seems that most SPARQL 
queries used in practice also only have variables in the subject and object positions 
(see, e.g. [DZS] ): still, general SPARQL queries can involve variables in any position 
(including in predicate positions, which correspond to the arrows of the schema). 
For example, we may use (John ?x Mary) to find all known relationships between 
John and Mary. To deal with this type of query, one may proceed as follows. 

If S is a graph (thought of as a schema with trivial path equivalences, which 
is in keeping with RDF schemas), then S itself is in fact a database instance on 
the schema Q from Example |3.1.3| A data fibration it : I -4 S can be considered 
simply as a map of graphs, i.e. a map of instances on Q. Taking its Grothendieck 
construction yields a map f(I) — > J(S), whereby each arrow from S (representing 
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a foreign key column) and each arrow from / (representing a cell in a foreign key 
column) has become a node. We can perform the original SPARQL query to this 
derived form of the database because our original predicate can now be accessed as 
a subject or object. For example our statement (John ?x Mary) would become the 
pair of statements (?x subject John) (?x object Mary). 

4.1. WHERE- less queries. The basic SQL query is of the form 

SELECT R 
FROM I 
WHERE W 

In this section we study queries in which the where-clause W is empty; we call these 
where-less queries. This situation is understood mathematically as follows. 

Definition 4.1.1. Let 5 be a schema. A probe on S is a functor n: R — >• S; 
the category R is called the result schema for the probe. Given a data fibration 
tt : I — » S the probe n is said to set up the lifting problem 

I 

■i 



Thus, in the presence of a data fibration tt, we may refer to the probe n as a 
where-less query. We define the set of solutions to the query, denoted T(n, tt) as 

r(n,7r) := {£: R ^ I \ tt o £ = n}. 

Example 4.1.2. Consider the data fibration n: I — > S given here: 





9 Ann 




# Bob 


# xl37 


# Dcb 


^139 




# xl44 






^Smith 




9 Jones 



7T 



FNames 



2C, 
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To find two people with the same last name we would use the where-less query 



where both n(Li) 









R := 












n(L 2 ) 


= (• 


Person Last^ ^ 



s 



LNamcs 



). There are two people (Ann 



Smith, Bob Smith) with the same last name, so we may hope to get as our result 
set {(xl37, Smith, xl39)}. 

Here is how to compute the result set for our query. We are looking for functors 
I: i? — > / that make the diagram 

(15) 




R 



S 



commute. This means choosing two "downward sloping" arrows in / with the same 
target. 

Using this query, we indeed find all pairs of persons in / that have the same last 
name. Unfortunately, this query would return five results, which we can abbreviate 
as 

(16) (a;137, Smith, xl39), (zl39, Smith, xl37), 

(xl37, Smith, xl37), (xl39, Smith, zl39), (xlU, Jones, xlU). 

The first two are what we are looking for, but they are redundant; the last three 
are just duplications (e.g. Deb Jones has the same last name as Deb Jones). We 
will deal with these issue in Example |4.1.5| after we discuss morphisms of queries. 

Definition 4.1.3. Let S be a schema. Given two probes n\ : R\ — > S and n 2 : R 2 — > 
S, we define a strict morphism from n\ to n 2 , denoted /: n\ — > n 2 , to be a functor 
/: i?i — > R 2 such that n 2 o f = n\. Let Prb(.S') denote the category whose objects 
are probes and whose morphisms are strict morphisms. In the presence of a data 
fibration n : I — > S, we may refer to / as a strict morphism of where-less queries 



(as in Definition 4.1.1 1 



Given a strict morphism /: ri\ — > n 2 , one obtains a function T(/, tt) : T(n 2 , 7r) — > 
L(ni,7r), because any lift l 2 in the diagram 

(17) 




i.e. with n 2 = tt o £ 2j induces a lift i\ := £ 2 o /: i? x 
have produced a functor L(~, tt) : Prb(S') op — > Set. 



/ with ni = 7r oti. We thus 



Remark 4.1.4. We use the term strict morphism of probes in Definition |4.1.3 be- 
cause a more lax version of morphism will also be defined in Definition 5.1.2| 
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W here as above we consider commutative triangles of categories (e.g. n 2 o / = n\ 
in ( IT I ) and call the resulting category Prb(5), the lax version will allow for nat- 
ural transformations (e.g. n 2 ° / n\) and w ill be denoted Prb(5). The functor 
r(-,7r): Prb(S) 



Set defined in Definition 
(which we give the same name), T(—,tt) : Prb(5) 
in Section [5j] 



4.1.3 



can be extended to a functor 
Set. This will all be discussed 



Example 4.1.5. We again consider the situation from Example |4.1. 2 [ where we were 
using the query n : R — > S to look for pairs of people who had the same last name. 
There we had two problems: 

• every person has the same last name as him- or her-self, so we were getting 
degenerate answers, and 

• given two people with the same last name, we can reverse the order and 
get another such pair, so we were getting order-redundancy. 

In order to deal with the first issue, consider the strict morphism of queries 
R = 



• P1 ^ 








R 2 ■= 




f 


► 
















-Li 









-> s 



where f(L\) — /(£ 2 ) = L, and where n = n 2 o f. This induces a function between 
the solution sets; i.e. we get a function 

r(/,7r):r(n 2 ,7r)^r(n,7r). 

In our example (16 1, the image of this function is precisely the set of duplicates. In 
other words, if we delete the elements in the image of T(/, it) we get 

r(n,7r) -r(n 2 ,7r) = {(xl37, Smith, xl39), (xl39, Smith, xl37)}. 

In order to deal with the remaining redundancy issue, consider the swap map 
s: R R given by s(L{) — L 2 and s(L 2 ) = L\. Note that n o s = n. Thus we 
have a strict morphism of where-less queries s : n — > n, which induces a function 
T(n, 7r) —> r(n, 7r). By taking the orbits of this function, we effectively quotient out 
by order-swapping. In fact our swap map acts not just on (i?, n) but on (i? 2 , n 2 ) as 
well, and so we can combine this method with the one above to obtain the desired 
answer, the one element set consisting of the pair (Ann Smith, Bob Smith), in 
unspecified order. 

Proposition 4.1.6. Let 5: S — > Set be an instance and tt: I — > S the induced data 
fibration. Given any where-less query n: R — > S , there is an isomorphism 

r(n, 7r) ^> lim((5 o n). 
Proof. Consider the fiber product diagram 

R XsI-^-I 



R 



S. 
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The set T(n, ir) of functors £ : R — > I for which 7r o £ = n is in natural bijection with 
the set of functors £' : R — > R x s I for which ir' o £' = Thus, by Proposition 
|2.3.8[ we may assume that R = S and n = ids- In other words, we have reduced 
to showing that given a functor 6: S —> Set with data fibration ir : I — >• S, there is 
a bijection 

r(id s , 7r) = Hom Ca t /s (-5*, I) ^> Um <5. 

Consider the terminal functor out of S 1 , which we denote t: S — > [0]. Let {*} 
denote the one-element set, which is the same as the terminal object in [0]-Set. 
Note that lims S = HtS (where the migration functor II is defined in Definition 



2.2.2). Thus we have 



limJ 3 Hom Se t({*},lim(5) s Hom [0 ]_set({*}, n t <5) = Hom S -s e t(A t {*}, S). 



The result follows by Lemma 2.3.7 since we have j (A t {*}) = S and J (S) = I. 

□ 



4.2. General lifting queries. In this section we tackle the more general lifting 
query. These closely resemble graph pattern queries, as used in SPARQL (see 
|PSj ). We will show how to perform queries like (and including) the one suggested 
in Example |4.0.4| where we hoped to find the last names of our new acquaintances, 
Bob and Sue. We begin with the definition. 

Definition 4.2.1. Let S be a schema and tt: I -4 S a data fibration. A query on 
7r is a solid-arrow commutative diagram of the form 



W 



R—^-S 



The categories W and R are called the where- category and the result schema, re- 
spectively. We define the set of solutions to the query, denoted L m,p (n,7r), to be 
the set of lifts £ making the diagram commute. Precisely, 



L m ' p (n,7r) := {£: R^I | it o £ = n and £om = p}. 
We are now ready to tackle our main example problem, Example |4.0.4| 



Example 4.2.2 (Part 1: setup). Recall the SPARQL query presented as (13 1 in 



Example |4.0.4[ in which we wanted to find information about our new friends Bob 
and Sue. We will use a lifting problem to state this query; to do so we need to 
come up with a result schema R, a constraint schema (or "where-clause") W, and 
a mapping m: W — > R embedding the known objects into the result shape. In this 
example we will present m, W, and R. In Example |4 . 2 . 3 1 we will explain the lifting 
diagram for the query and show the results. 
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In order to find our friends Bob and Sue, we will use the following schemas for 
W and R: 



Cambridge 



Cambridge 



financial 
sector 



a first 
name 




a last 
name 


CI 




a city 



a last 
name 




The functor m: W — > R is indicated by sending each object in W to the object 
with the same label in R; e.g. r MIT~ 1 in Ob(T / F) is sent to r an employer" 1 in Ob(i?) 
because they are both labeled Y. 

To orient oneself, we suggest the following. Count the number of constants 
in the SPARQL query (13 1 - there are 6 (such as Bob, Cambridge, etc.); this is 
precisely the number of objects in W. Count the combined number of constants 
and variables in the SPARQL query - there are 14 (there are 8 variables, such as 
?marriage, ?empoyeds, etc.); this is precisely the number of objects in R. Finally, 
count the number of triples in the SPARQL query - there are 13; this is precisely 
the number of arrows in R. These facts are not coincidences. 



Example 4.2.3 (Part 2: Lifting diagram and results). In Example 4.2.2 we showed a 
functor m: W — >• R that included the set of knowns into the relevant result schema 
for the SPARQL query in (13 1. In this example we will provide a lifting problem 
of the form 



(18) 



W 



e / 



R 
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which serves to pose our query to the data I on schema S, at which point we can 
ask for all solutions £. So far, W, m, R, and S have been presented, / and it have 
been assumed, and the set of is is coming later, so it suffices to present p and n. 



One should refer to our presentation of S as ( 14) in Example 4.0.4 The functor 
n: R — > S should be obvious from our labeling system (for example, the object 
El= r an employed person" 1 in category R is mapped to the object E= r an employed 
person" 1 in category S). 

Suppose 7r : / — > S is our data fibration, and assume that it contains enough 
data that the constants in the query have referents. There is an obvious functor 
p:W^tI that sends each object in category W to its referent in I. For example, 
we assume that there is an object in / labelled r MIT n , which is mapped to by the 
object Yl= r MIT n in W. 



We have thus set up our lifting problem (18). Lifts £: R I making both 



triangles commute (£ o m — p and n o I = n) are solutions to the query. By 



Proposition 4.2.4 below, the set T = L™' p (n,7r) of solutions can be given the form 
of a database instance on R in which every table has the same number of rows 
(namely the cardinality of L). 

In this example, we have assumed instance data exists for S, but we have not 
shown it explicitly Since the results of a query depend on the instance of the 
database, it does not make much sense to show the results of our query on an 
imaginary instance /, but we will play along anyway. We know sufficiently much 
information about Bob and Sue that they are probably the only couple in the world 
that fits, so let's assume that the cardinality of our result set L is 1. In other words, 
every table in the result schema R would have one row. The relevant part could be 
collected into a single table and might look something like this: 
(19) 



Marriage 


Id 


Husb: 


First 


Last 


City 


Wife: 


First 


Last 


City 


G3801 


M881-36 


Bob 


Graf 


Cambridge 


W913-55 


Sue 


Graf 


Cambridge 



The following proposition says that for any query on a dataset /, there is a 
canonical embedding of the query result back into /. 

Proposition 4.2.4. Let 5: S — > Set be a instance on a schema and n: I — > S the 

associated data fibration. Suppose given a query (lifting problem) 




with solution set T m,p (n,Tr) 6 Set. Considering this set as a constant functor 
T : R — > Set (given by T(r) — T m ' p (n,ir) for all r 6 Oh(R)), there is an induced 
map of R-sets, 

Res: T A n 5. 

Proof. Let T(n, ir) — {£: R — >I\tto£ — n} denote the set of solutions to the 
where-less query n: R — ► S. Clearly, we have an inclusion T m ' p (n, ir) c — > T(n,w). 
By Proposition 4.1.6| there is an isomorphism T(n, tt) = linifl(<5 o n). 



Let t: R — > [0] denote the terminal functor. We elide the difference between 
a set and a functor [0] — > Set; for example, we consider the set T m ' v (n : ir) as a 



DATABASE QUERIES AND CONSTRAINTS VIA LIFTING PROBLEMS 31 

functor [0] — > Set. It is easy to show that for any functor G: R — > Set there is an 
isomorphism lim^ G = n t G, so in particular we have linijj(<5o n) = IT(<5 ° n). Thus 
we now have the following map of [0]-sets 

r m ' p (n,7r) ->n t ((5on). 

By the (A t , II 4 )-adjunction, there is an induced map A t (T m ' p (n, it)) — > (5 o n) of 
i?-sets. The result follows, since A t (T m ' p (n, n)) = T and 5 o n = A n S. 

□ 



5. Formal properties of queries 

In this section we will discuss some formal properties of the machinery developed 
in earlier sections. For example we will show that the queries on a given database 
can be arranged into a database of their own and subsequently queried. In other 
words, we can create graph pattern queries of smaller queries, whose solutions 
consist of coherent solution sets for these smaller queries. This involves defining 
a category of queries and proving that finding solutions is functorial. We also 



extend some results from Section 3.4 giving more detail on the interaction between 
data migration functors, on the one hand, and query containment and constraint 
implication on the other. 



5.1. New data fibrations from old. 



Theorem 5.1.1. Let n: I — > S be a data fibration and let B be a category. Then 
the induced functor ir B : I B — > S B is a data fibration. If S B : S B — > Set is the 
associated instance, then for any F: B — > 5* in Ob(S B ), there is a bijection 

8 B (F)^T(F,ir). 

Proof. We begin by drawing a figure for reference: 
(20) / 




Suppose that F\ , F 2 : B — > S are functors. Given a functor £i : B — > I with tto£ 1 = 
Fi and a natural transformation a: F\ — > F 2 , we must show that there exists 
a unique functor £ 2 : B — s- / and natural transformation (3 : i\ — > l 2 such that 
tto£ 2 = F 2 and 7r(/3) = a. For any object b S Ob(B), the map ah : Fi(b) — > F 2 (b) in 
S together with the object £i(b) € /, such that ir(£i(b)) = Fi(b), induces a unique 
arrow : £\{b) — > ib in I for some ib S Ob(i), because tt is a data fibration. Define 
£ 2 (b) = ib- This defines £ 2 : B — > / on objects. 
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Now suppose that /: b — > b' is any morphism in B. Applying what we have so 
far, we get a functor X — > Y , where 



(21) X := 



h(b)^^£ 2 (b) 
^{b')—^l 2 {b>) 

Pb' 



F 1 (b)^^F 2 (b) 



Fx(f) 



F 2 {f) 



F^b') F 2 {b>) 



=: Y 



and we get a commutative diagram 




In order to complete our definition of £ 2 , our goal is to fill in the missing side (the 
dotted arrow labeled "?") in square X. 

The map F 2 (f) : F 2 (b) F 2 (b') in S together with the object £ 2 (b) e Ob(J) with 
ir(£ 2 (b)) = F 2 (b) induces a unique arrow h b > : £ 2 (b) — > j b i for some j b > € Ob(7) with 
7r(jb) = b'. But now we have two maps in I over the composite Fi(b) — > F 2 (b') both 
with source h(b) G Ob(7), namely /3 b , o l x {f) : 4(6) -> £ 2 (b') and h b > o f3 b : i x (b) 
j b i. Since n is a data fibration, their codomains must be equal, giving a map 
£ 2 (b) —> £ 2 (b') = j b i, and we have completed square X in Diagram (21 1. We have 
now defined our functor £ 2 : B — > / and natural transformation ft : £\ — > £ 2 over a, 
and they are unique: we made no choices in their constructions. 

By definition, n B : I B ->• S B is a data fibration. Let S B := d(ir B ) : C B -> Set 
be the associated instance and F £ Ob(S B ) an object. We can consider F as a 

map [0] S B , and S B (F) is isomorphic to the set of lifts in the left-hand diagram 



[0] 



s 1 



B 



which by adjointness is in bijection with the set of lifts T(F, it) in the right-hand 
diagram. Therefore we have S B (F) = T(F,n), completing the proof. 



4.1.3 



The following definition of Prb(S) extends the notion of Prb(5) from Definition 
Prb(S) C Prb(5) is a subcategory with the same set of objects. 



Definition 5.1.2. Let S be a category. We define the category of probes on S, 
denoted Prb(5), as follows. 

Ob(Prb(S)) = {(A,F) \ A e Ob(Cat), J F: A^5a functor} 

Hom Prb(s) ((^, J F 1 ),(^',F')) = {G,a) \ G: A' -> A, a: F o G ^ F'} 

A , G A F 
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Remark 5.1.3. In the presence of a data fibration ir: I — > S, a probe F: A — > S 
sets up a where-less query on n for which the results are the lifts £ £ T(F,ir) for 
the diagram 

>I 

-* 

i / 
/ 

!/ V 

A >5. 

F 

We call these where-less queries to emphasize that the where-category (upper left 
of the diagram) is empty. 

For any category B, there is an obvious functor S B — > Prb(5). The following 
corollary extends Theorem |5.1.1| in the obvious sense. One way to understand its 
content is that we can query over where-less queries. For example, we could create 
a diagram of where- less queries and look for coherent results for each. Corollary 
|5.1.4| implies that given a morphism between two where-less queries on S and given 
a result for the first query, there is an induced result for the second query. We will 
deal with the case of general queries (those having non-trivial where-categories) in 
Proposition |5.2.2| 

Corollary 5.1.4. Let n: I — > S be a data fibration. Then the induced functor 
7f = Prb(Tr)) : Prb(I) Prb(S) 

is a data fibration. Associated to tt is the instance 5: Prb(5) — > Set given by 

5(-)=T(-, tt). 

Proof. Proving this corollary is really just a matter of writing down the appropriate 
diagram. In order to show that 7f is a data fibration, we choose an object £: A — > I in 
Prb(I) with Tf(l) — F: A ^ S, we choose a morphism (G, a) : (A, F) -> (A', F') in 
Prb(S), and we show that there exists a unique morphism (G, j3) : (A, £) — > (A' , £') 
in Prb(J), for some £' : A' — > /, such that tt(/3) = a. In diagrams, we begin with 
the solid-arrow diagram 

(22) e „ - J 




and hope to find £' : A' -> I and /3: £ o G £'. 

We have tt o [£o G) — F o G. Applying Theorem 5.1.1 there is a unique induced 
functor £' : A' —> I and natural transformation f3: £ — >• £' such that ir(/3) = a, 
having the required properties. This completes the proof. 

□ 

Next we present two examples of morphisms of where-less queries, namely pro- 
jection and indirection. In some sense, these generate all such morphisms. 

Example 5.1.5 (Projection). Let 5: S — > Set be an instance and let tt: I — !> S be 
the associated data fibration. Let n € N be a natural number. The n-column table 
schema, here denoted C n , is the category with an initial object K, precisely n other 
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objects, and precisely n non-identity arrows; it follows that the category looks like 
an asterisk (or "star schema"), e.g. Cg is drawn: 




A functor p: C n — > S is called an n-column table schema in S. For each object 
x G C„, we call p{x) € Ob(S) a column of p and we call p(K) the primary key 
column of p. In fact, p is a probe or where-less query. The result set T(p, tt) can be 
thought of as the set of records for instance S in table p; indeed T(p, w) is isomorphic 
to 5(p) as sets. 

For any injection h: {1,2,..., n'} {1,2,..., n}, there is an induced functor 
C(h): C n i —> C n , which we can compose with p to get a new morphism p' :— 
po C(h) : C n ' —> S and a strict morphism of probes p — > p' :— po C(h). A record in 
table p is given by a lift I as shown to the left: 



(23) 




r c(h \ <- 













.p c{h) , .v 







Prb(7) 

Prb(7r) 

■Prb(S*) 



and composing i with C{h) gives its projection as a record in table p' . Thus h 
induces a function T(p, it) — > T(p',ir), and its image is the associated projection. 
The righthand diagram in (|23[) is another way of viewing the lefthand diagram. 



Remark 5.1.6. In Example |5.1.5| we did not really need to assume that the function 
h was injective. If h were not injective, then the morphism of queries C(h) would 
result in some duplication of columns rather than a pure projection. 



In Example |5.1.5| we changed the shape of the result schema and used a strict 
morphism of probes (the natural transformation poC(h) -4 p' was the identity). In 
Example |5 . 1 . 7| we will keep the result schema fixed but allow a non-strict morphism. 



Example 5.1.7 (Indirection). Let R = [1] = 



and let S be the schema 



S:= 



a person 


lives at 


an address 


is in 


a city 







There are three non-constant functors R — > 
Fb c ; there is a natural transformation a: F a i, 
(3: F ac — > Fi, c . Thus we get two morphisms in Prb(S'), namely 



S, which we denote F a b,F ac , and 
-> F ac and a natural transformation 



(id*, a) : (R, F ab ) -> (R, F ac ) and (id fl , 0) : (R, F ac ) -> (R, F bc ). 
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Just to make a picture that looks like previous pictures, we could draw this as 




Suppose tt: / — > S is an instance. We can take global sections r(— ,7r) for each 
of these three probes and obtain maps between the result sets by Theorem |5.1.1| 

T(F afc , tt) — ► T(F QC , tt) — ► T(F bc , tt). 

In other words, the morphism of queries induces a morphism of result sets. Simply, 
given some person and her address we can return a person and the city she lives 
in; given some person and his city we can return an address and the city it's in. 

We end this subsection with an example of a query on queries. 

Example 5.1.8. Let tt: / — > S be a data fibration. Consider the lifting problem 



(24) 



K := 



Prb(J) 

Prb(Ti-) 

■Prb(S) 



The arrow labeled n represents three categories mapping to S and some transforma- 



tion diagrams between them (see Definition 5.1.21. For example, we could consider 
two result schemas R\ , i?2 — > S with a common projection schema R —> S (see 



Example 5.1.5). A lift I would be a coherent sequence of solutions to these three 
queries. 

If we wanted a specific result for say L: Ri — > /, we could complete Diagram 



(24 1 to the square 



n 



Prb(J) 

Prb(7r) 

¥ 

Prb(5) 



where m(» Ll ) = u Rl and p(» Ll ) = L. 

To understand what this means, we investigate its solution set T m - p (n, Prb(7r)). 
It is useful to consider Proposition |2.3.6| in conjunction with Corollary |5.1.4| We 
see that T m ' p (n, Prb(7r)) is in bijection with the subset of r(n(i?2)> tt) consisting 
of those results on n(i?2) whose projection to n(R) is the same as the projection of 
the given solution L. 

5.2. The category of queries. We are now ready to generalize the category 
Prb(5) of where-less queries on S to a category of all (lifting) queries on S. 



Definition 5.2.1. Let tt: I — > S denote a data fibration. We define the category 
of (lifting) queries on tt, denoted Qry(7r) as follows. The objects of Qry(7r) are 
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commutative diagrams as to the left 



W — ^— s- / 



R 



V 
S 




and the morphisms (F, G, a, 7): (i?, W, n,p) — > (-R', W', ri',p') are diagrams as to 
the right, where 

7r o 7 = a o m , so, in particular, 
iropoG = noFom' and 7rop = n o m'. 

Proposition 5.2.2. Lei n: I ^ S be a data fibration, and suppose given the dia- 
gram to the left: 





Then there exists a unique morphism of queries (F, G, a, 7) : (i?, W, n, ,p) — > (i?', W , 1 
as to the right. 



Proof. This is a direct application of Theorem |5.1.1| Indeed, in place of Diagram 
( 20 1 , we draw 




W H-a 



The unique functor and transformation labeled £2 and j3 given by the theorem serve 
as p' and 7 here. 

□ 
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Theorem 5.2.3. Let tt: I — > S be a data fibration. Then T ' ( — ,7r): Qry(7r) — > 
Set is functorial. That is, given a morphism of queries 




there is an induced function, natural in Qry(7r), 

r m < p (n,7r) — >T m '' p '(n / ,ir). 
Sketch of proof . Suppose given a lift £: i? — s- / in L m ' p (n,7r). By Corollary 5.1.4 



we 



have a map £' : R' — > /, with ttoI' = n', and a natural transformation /3 : £oF 
with 7T o /3 — a. We need to show that £' o m' = p' and j3 om! — 7. But this follows 
from Theorem 15.1.11 and the definition of data fibration. 

□ 

Remark 5.2.4. Given a data fibration tt: I — > S, we sometimes denote the functor 
r _ ' _ (— ,7r) simply by 

r(7r) : Qry(Tr) -> Set. 

Remark 5.2.5. There is a way to express the set of solutions to a lifting problem 
using limits. Let n: I — s- S be a data fibration, and consider the query 




The functor m induces a function G m : T(n,ir) — > T{nm,Tx), and we can consider 
p G T(nm, 7r) as an element in the codomain. The bijection 

(25) T m -P{n, tt) 3 r(n, tt) x r(nm , x) {p} 

expresses the set r m ' p (n,7r) of solutions to the lifting problem as the fiber of G m 
over p. 



5.3. Data migration functors. Recall (from Definition 2.2.21 that, given a func- 
tor F: S — > T, three data migration functors are induced between the categories 
S-Set and T-Set. The most straightforward is denoted A F : T-Set -» S'-Set. It 
has both a left adjoint, denoted Y.p : 5-Set T-Set, and a right adjoint, denoted 
II F : S Set ->■ T-Set. 

Let us begin by giving a description of Hp in terms of where-less queries (see 



Section 4.1 1. Recall that for any object d S Ob(T) the "comma" category (d i F) 

F(c)} 



is defined as follows: 

Ob(dlF) = {(c,f)\ceOb(S),f:d 
Hom WF) ((c, /), (c', /')) = {9: c c' I /' o F( 5 ) = /}. 
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There is a natural functor rid '■ (d \. F) —> S, and given a morphism h : d — > d' in T 
we have a morphism (d' 4- F) — >• (<i J. _F) , or more precisely n^< -> n^, in Cat /<j. 



Proposition 5.3.1. Lei F: 5 - 

with associated data fibration 7r : 
associated where-less query 



- T be a junctor and 7 : 5* — > Set an instance of S 
I — > S. Given any object d G Ob(T), there is an 



and we have n^(7)((i) = r(?id,7r). Moreover, a morphism d — > d' in T induces 
a strict morphism of where-less queries rid' nd ■ thus we have a functor T — > 
Prb(7r) op . Then U F (-y) : T -> Set is the composition 



T 



^> Prb(^)°P It 



^ Set. 



Proof. Let F, 7, 7r, d, and : (d 1 F) — > S 1 be as in the proposition statement. By 
Proposition 4.1.6 we have r(nd,7r) = linifl(7 o n.^). This is exactly the formula 
for Hp('y)(d) by |Mac| Theorem X.3.1], since Hp is a right Kan extension. The 
statement for morphisms follows similarly. 



While Proposition |5 .3 . T] provides an interesting relationship between right push- 
forwards and queries, it does not allow us to relate graph pattern queries on a 
database with queries on its right pushforward. In the following paragraphs, we 
will show briefly that graph pattern queries do transform nicely with respect to 
data migration functors S and A. 

We begin by discussing the left pushforward functor. Given a functor F: S — > T, 
we have a migration functor T,p: S^Set — > T-Set. Suppose 8: S — > Set is an 
instance with associated data fibration ir : I — > S. There is a nice relationship 
between the left pushforard T,p5 £ T-Set and the composite functor Fott e Cat 
One might like to have an isomorphism F o tt s J (Y,pS), but this is not quite true; 
indeed, F o n is not in general a data fibration, whereas J (T,p S) is. However, there 
exists a factorization system on Cat, called the (initial functor, discrete opfibration) 
factorization system (see |Jolj ). which allows us to "complete" F o tt to a data 
fibration, and this completion is indeed isomorphic to J (T,pS). 

If S £ S'-Set and e € T-Set are instances, then there is a bijection between the 
set of natural transformations Y.pS — > e and the set of commutative diagrams 



J(S) ./(e) 
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Given a query on -Kg, we clearly obtain an induced query on 7r e , and a solution to 
the former yields a solution to the latter: 



R 



S 









m 














i / ^ 


f Y 



T. 



We state this precisely in the following proposition. 

Proposition 5.3.2. Let F: S -t T be a functor, S € S-Set and e S T-Set 

instances, and Y.pS — > e a map ofT-sets. There exists an induced functor of query 
categories and a natural transformation diagram: 



Qry(^) 



Qry(7r e ) 



Set 

Proof. The proof follows from the discussion above. 



We now consider the case that S = Ape. 

T be a functor, let e : T 



Set be a functor, let 



Proposition 5.3.3. Let F: S 

8 = Ape'- S — > Set be its pullback, and let ns and ir e be as in Diagram (26). Then 



the results of any query on us are the same as the results of the induced query on 
7r e . That is, we have a natural isomorphism diagram 



Qry(7T<5) 



Qry(TTe) 



Proof. Consider the diagram 
(26) 



Set 

J(S) ^/(e) 

T6 



s- 



■ T, 



which is a pullback by Proposition |2.3.8| Given a query on ng, we obtain a query on 
7r e as in Proposition |5.3.2[ but now the function from solutions for tts to solutions 
for 7r e is a bijection, by the universal property of pullbacks: 



W 



/(e) 



Y 

R 



S 



Y 

T. 



□ 
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6. Future work 

This paper has set up an analogy between database queries and constraints 
on the one hand, and a now classical approach to algebraic topology — the lifting 
problem — on the other. Data on a schema is analogous to a covering space or 
fibration: the local quality of this fibration is determined by constraints, and the 
local sections satisfying various properties are queries. 

There are a few interesting directions for future research. The first is to make 
a connection to the relatively new field of homotopy type theory (HoTT) (see 
|Awo] . [Voe] ). The idea is that instead of two paths through a database schema 
being equal, one could declare them merely equivalent] if paths are declared equiv- 
alent in more than one way, these equivalences may also be declared as equivalent 
(or not). Two observations on data may not be dcfinitionally equal, but provably 
equal, and we consider the proofs and the differences between proofs as part of the 
data. To make this connection, the schema of a database should be a quasi-category 
f |Jo2| . |Lur] ) X rather than an ordinary category. Each higher simplex encodes a 
proof that different paths (or paths of paths, etc.) through the schema are equiv- 
alent. We might replace the instance data by a functor (map of quasi-categories) 
X —> Type, where Type is the quasi-category of homotopy types. 

Another direction for future research is to use topological tools to investigate 
or "mine" data. For example, given a functor 5: S — > Set, we can compose with 
the functor i : Set -4 Top which sends each set to the corresponding discrete 
topological space. The homotopy colimit of i o 5 is a topological space, of possibly 
any dimension and homotopy type, that encodes the connection pattern of the data. 
This space is homotopy equivalent to the nerve of the data bundle, 

hocolim(i o 5) ~ N( J S) 

(see Dug|). Thus we could report homotopy invariants of the data S, such as 



connected components, loops, etc. The question is whether these invariants would 
be meaningful and useful. For schemas of classical mathematical interest, such as 
the simplicial indexing category S — A op , the homotopy colimit of i o S is exactly 
what we want; it is the geometric realization of 5. It remains to be seen whether 
such homotopy invariants may be useful in other contexts; e.g. there may be some 
connection to the analysis given by persistent homology (see |Ghr j . [Car] ) . 

A third and fairly straightforward project would be to adapt Garner's small 
object argument (see [Gar]) to our notion of constraints. Garner's argument works, 
and provides nice universal properties, in the case of what we have called "universal 



constraint sets" (see Section 2.3.21. The question is, if we apply his techniques to 
local constraints, such as those in Example |3.2.6| used to declare that one table is 
the product of two others, does his procedure still result in a data fibration with all 
the nice universal properties enjoyed in the universal case? We conjecture that it 
will. One should also check whether the results obtained from that procedure agree 
with those from the so-called universal chase procedure (see [DNR ). Indeed, they 
should provide equivalent results, since both claim to be universal in the same way. 
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